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Evaluation Structure (MCES) as a tool which the author 
recommends for command and control (C2) planners to use when 
addressing interoperability management problems. The framework 
of MCES is used to identify the inadequacies of the Marine 
Corps Technical Interface Concepts (TIC) as an interoperability 
management tool and provides some insight into how to better 
define interoperability requirements in terms of message 
exchange occurrences (MEOs). MEOs are the building block of 
interoperability, and they can be stored along with their 
elements of decomposition in an integrated interoperability 
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I. INTRODUCTION 



A. STATEMENT OF THE PROBLEM 

In the past decade interoperability problems have become 
intense as technological advancements in the electronic 
industry drive communications equipment. Designers of command 
and control (C2) system architectures may have been overly 
influenced by equipment specifications. In designing a 
communication system to support a C2 architecture they have 
concentrated primarily on capabilities derived from 
technological advancements, rather than on information flow 
and mission requirements. In some instances, communications 
system equipment interoperated effectively, while the C2 
architecture to be supported was unable to operate effectively 
as a system. [Ref. 1] 

When individuals or command centers within a C2 
architecture are not able to interoperate, they lack the 
ability to effectively function as a system working towards a 
common goal. The lack of interoperability in a C2 architecture 
could manifest itself in several forms: (1) individuals not 

understanding or misinterpreting a message, (2) command 
centers not able to exchange valuable military information 
about themselves, or (3) individuals and command centers not 
fully understanding operational procedures. 
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A major goal of the DOD is to provide military planners 
with accurate, detailed information about C2 system 
requirements, about the interrelationship of tactical C2 
systems, and about the impact that a particular C2 architec- 
ture will have on the system as a whole, [Ref, 2: p, 1] 

Interoperability of command and control systems can be 
defined in terms of "information flow". However, presently 
there is no universal accepted methodology within the 
Department of Defense (DOD) for documenting "information flow" 
in a command and control architecture, [Ref, 2] 

In order to address the interoperability problem of command 
and control architectures, a method for identifying, capturing, 
organizing, and accessing information necessary to describe 
current and projected command and control systems must be 
adopted, [Ref, 3: p, 4] The methodology must be able to 

provide a detailed view of a command and control structure, and 
be applied as a dynamic analysis tool for problem-solving, 

[Ref. 2: p. 1] and [Ref, 3: p, 1] 

B. OBJECTIVE OF THESIS 

This thesis addresses some of the challenges issued by 
Major Steven L. Pipho, USMC, in his article "Cutting the Gordian 
Knot of Interoperability: A Sys tems-Engineer ed Solution to the 

Problem of Interoperability Modeling," [Ref. 2] Pipho asserts 
that: 

The military faces a formidable challenge today in the area 
of command, control, and communications. Powerful, 
[communications] systems which exploit a rapidly expanding 
technological base are fast becoming realities; yet, issues 
concerning their integration into the larger context of a 
command and control architecture remain unresolved. 
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Military planners require clearly defined standards of 
compatibility and interoperability to retrofit fielded sys- 
tems, modify those currently in design, and plan for futures 
ones. [Ref. 2: p. 1] 

The major effort of this thesis deals with expanding and 
applying a tool to enable analysts to effectively gain new 
insight into the problem dealing with interoperability of 
commmand and control architectures. Based upon Marine Corps’ 
efforts, an architecture is defined as: ”An aggregate or set 

of elements systematically associated and structured to 
accomplish a purpose that is characterized by the peculiar 
organization of its elements.” [Ref. 2: p. ii] Therefore, a 

command and control architecture [system] associates elements 
of command and control whose specific structure facilitates the 
exchange of information by communications to support the 
achievement of mission objectives. (See Phipho, 1986) 

[Ref. 2: p. 2 ] 

There are two foci in this thesis, (1) operational 
considerations and (2) methodological issue. 

1 . Operational Considerations 

After their attempt to design an air defense C2 
architecture using the Technical Interface Concepts (TIC) 
Concepts for Marine Tactical Systems, both the author and Pipho 
agreed that the methodology set forth in the TIC should be 
examined and analyzed for its ability to adequately address 
interoperability problems on an architectural level. This was 
undertaken by employing, as a test case, the Operational 
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Facility (OPFAC) tasks associated with a C2 communications 
architecture that is required to produce an air tasking order 
(Frag) . 

2 • Methodological Issue 

Conversely, by examining the procedures associated with 
the air tasking order, this thesis will verify the ability of a 
Lawson-like C2 Process model to practically describe service 
doctrine . 
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II, BACKGROUND 



A. DEFINING INTEROPERABILITY OF A C2 ARCHITECTURE 

Throughout history the military services have been plagued 
with interoperability problems associated with command and 
control (C2) systems. Interoperability of C2 systems is a very 
arduous topic to fully analyze, because the terms 
’’interoperability” and ”C2” have several connotations. As a 
result, one may not be sure of the intended meaning of the 
phrase ’’interoperability of a C2 architecture/system.” The 
following two subsections are written to provide a baseline 
definition for interoperability of a C2 architecture. 

1 . Interoperability 

For this thesis, the formal definition for 
interoperability, as defined in the Joint Chiefs of Staff (JCS) 
Publication 1, will be used: 

Interoperability is the ability of systems, units or forces 
to provide service to and accept services from other systems, 
units or forces and to use the services so exchanged to enable 
them to operate effectively together. [Ref. 4: A-3] 

Interoperability has a major implication that must be taken 

into account. A system must not only interoperate with other 

systems, but it should also operate effectively with its own 

units and forces as a complete system. In other words, there 

must be both intraoperability (definition of ’’system”) and 

interoperability in order to have effective operations. 
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To illustrate the above point, consider a Marine air 
defense system which is composed of the following control 
facilities/agencies: 

- Tactical Air Control Center (TACC) 

“ Tactical Air Direction Center (TADC) 

- Tactical Air Operation Center (TAOC) 

- Light Antiaircraft Missile Bat ter y ( LAAM) 

- Forward Area Air Defense Battery (FAAD) 

Each of these facilities/agencies are made up of several 
subordinate units and/or sections which perform unique tasks, 
such as the LAAM battery which has an Antiaircraft Operations 
Center (AAOC) and a Battery Control Center (BCC). If the 
subordinate units and/or sections within a f acility/agency are 
unable to interoperate among themselves, then that facility/ 
agency lacks interoperability. And if a facility /agency 
does not have interoperability within itself, then it can not 
operate effectively as a subordinate part of a larger organiza- 
tion. In order for an air defense system to be interoperable, 
interoperability must be established throughout the entire 
system. The hub of the Marine Corps’ air defense operation is 
the TAOC. (See Figure 2.1) The TAOC must be able to interoper- 
ate with the TACC/TADC, LAAM battery, and FAAD battery. If any 
of these organizations could not interoperate with the TAOC, 
then there would not be an air defense system. The air defense 
system requires that all of its facilities/agencies be inter- 
operable in order to be considered a system. 

The official Department of Defense (DOD) definition for 
command and control is: 
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Figure 2.1. A Simple Air Defense System. 
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The exercise of authority and direction by a properly 
designated commander over assigned forces in the accomplish- 
ment of the mission. Command and control functions are 
performed through an arrangement of personnel, equipment, 
communications, facilities, and procedures which are employed 
by a commander in planning, directing, coordinating, and 
controlling forces and operations in the accomplishment of 
his mission. [Ref. 3: p. 2-2] and [Ref. 5: p. 23] 

Therefore, C2 is the total and all encompassing process of 
a commander accomplishing a mission through the assets of his 
assigned forces. The commander controls and directs his forces 
by some means of communication, which can range from a simple 
manual technique (speech) to a fully automated facility, such 
as a naval communication station (NAVCOMMSTA). Thus, all forms 
of communication and their supporting facilities are only means 
which a commander and his forces utilize to pass information to 
one another, in order to interoperate and effectively 
accomplish the assigned mission. In support of C2, C2 systems 
are developed, acquired, and fielded. The JCS Pub 2 definition 
of command and control, and information system is used to 
define C2 systems: 

An integrated system comprised of doctrine, procedures, 
organizational structure, personnel, equipment, facilities, 
and communications which provides authorities at all levels 
with timely and adequate data to plan, direct and control 
their operations. [Ref. 3: p. 2-3] 

2 . Interoperability of a C2 Architecture 

Based on the above definitions of interoperability, C2, 
and architecture; "interoperability of a C2 architecture" will 
be defined for this thesis as: The ability of an aggregate set 

of control f acil tit ies/agencies associated with an architecture 
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to exchange services among themselves, so that the exchanges 
enable a commander to accomplish his mission. This definition 
emphasizes the C2 architecture and not the specific communica- 
tion system which supports it. 

Although interoperability of communications systems is 
important, the information requirements and functional 
relationships of a C2 architecture must first be defined. 

Then, the communication system to support a peculiar C2 
architecture and its interoperability requirements can be 
identified. Following this sequence will better enable 
planners of communications systems to design systems which will 
support a commander in accomplishing his mission, rather than 
one which usually limits him. [Ref. 2] 

B. HISTORICAL PRECEDENCE FOR THE WORK 

In the early 70’s, the Marine Corps realized it had a 
problem with interoperability of C2 systems and attempted to 
resolve this problem through the Landing Force Integrated 
Communications System (LFICS) program. During 1985 the LFICS 
program was redirected. The new thrust was to develop a concep- 
tual framework that could combine information requirements and 
information flow with the constraints imposed by a particular 
configuration of communications and information-processing 
equipment. [Ref. 1: p. 2] 

In the conceptional framework of LFICS, C2 doctrine and 
operational requirements generated information needs. These 
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information requirements were originally known as Needlines, 
later as Message Exchange Occurrences (MEOs). A MEO summarizes 
a requirement for information exchange between two nodes. A 
MEO consists of a sender, receiver, message to be transmitted, 
and the circuit medium in which to pass the message. (See 
Figure 2.2). Above the line is the message, below the 
circuit. The flowline shows sequence and simple timing on the 
network. MEOs could be chained to one another to form a net- 
work that represented information flow over time. (See Figure 
2.3) [Ref. 1, 11] and [Ref. 6] 

At the heart of the LFICS architecture was a large 
information base which consisted of a number of related 
databases. It was planned that the LFICS information 
base would contain information on the composition of MEOs 
(source nodes, sink nodes, message types, and circuit medium) 
and communications equipment specifications. After the 
construction and maintenance of this information base, it was 
contemplated that system planners and managers would have a 
baseline from which to manage their systems. [Ref. 1: p. 2] 

The author^s interpretation of the LFICS information base 
is depicted in Figure 2.4. This interpretation structures the 
information base as a hierarchy of databases. Each database 
points to other databases which were either a subset or 
decomposition of a higher order database. For example, the MEO 
database would point to the C2 nodes database, message types 
database, and the circuit standards database. 
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"Given doctrine and operational requirement, 
a need for information is generated" 



Air Defense SAM 



TAOC Nodal Task: 



Elemental Task: 



^TAO^ 

(SOURCE) 



Evaluate, select and assign 
weapons to meet enemy air 
threats. Control engagement 
of enemy air threat by using 
surface-to-air missiles. 

Engage enemy air threat 
using LAAM unit 

Tactical Alert (Message) / . a a I 

Radio Digital (Link) y LAAM ) 

(SINK) 



Figure 2.2. A MEO for an Air Defense Envelope. 
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Given 



MEOs 




"String MEOs together to represent the information flow overtime" 



FLOWLINE 






TAOCV Tactical Alert ^ /dascY Tactical Alert ^ / LAAM 1 

I -1 ' Raclio Digital I J 



Radio Digital 
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►K- 



Time Period 2 



Figure 2.3. Flowline for an Air Defense Example. 
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Figure 2.4. An Interpretation of the LFICS Information Base. 
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An information base would be useful to many different types 
of users. Below are six broad user areas suggested by Pipho 
[Ref. 1] in his point paper titled ” A Development Strategy for 
a LFICS/C4I Architecture": 

1 . System Developers 

System developers have an obvious need for a [LFICS] 
information base . . . . the nature of the job requires 
them to extend their knowledge of the current communica- 
tions systems to assess future requirements. 

As sophisticated systems are proposed and accepted, the 
R&D community must ensure that diverse systems can be 
integrated efficiently into the general architecture. A 
typical application program would likely extract information 
from one database containing equipment specifications, 
system components, and interoperability standards such as 
interfaces, protocols, etc., and information from another 
dabase on how the various sytems are to be used, where they 
would be deployed, and the number and kind of skills required 
to operate and maintain a system. Additionally, an R&D 
database could contain information on engineering change 
proposals for systems under development to enable a project 
officer to ascertain the effect of a proposed modification. 

2 . The Fleet Marine Forces 

A good applications program for the [Fleet Marine Force] 

FMF would assist the [communication electronic officer] CEO 
or communications officer in the detailed planning of his 
communications "order of battle." He may want to access a 
database to gain detailed specifications of the equipment 
that is organic to his unit. Or, perhaps, he would want to 
analyze the loading of his particular node by examining the 
quantity of data and data rate he needs to successfully 
pass information between a sender and receiver for a 
particular type of exchange. 

3 . Acquisition Managers 

HQMC recently requested MCTSSA and MCDEC to comment on a 
proposal to use the LFICS study developed by TRIAD Corpora- 
tion to ascertain the [communication security] COMSEC 
requirements for the 1990’s. The idea was to examine the 
information needlines [MEOs] and flowlines in the loading 
analysis, count the number of secured nets, note their type, 
and produce a final count of COMSEC equipment by category. 
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4 . Doctrine Developers 



Doctrine plays a key role in the [LFICS] architecture. It 
fundamentally influences the needlines [MEOs] and flowlines 
of the communications systems because it defines the elements 
of a combat team and the relationships between them. An 
applications program for members of the Doctrine Branch or the 
Advanced Amphibious Warfare Study Group would be one which 
would access a database, extract organization and C2 informa- 
tion, and explore the effects of doctrine changes on the 
communications system by substituting or changing the 
composition of a combat force. 

5 . Educators 

The [LFICS] information base can be viewed as the 
repository for all [C2] information. Students at the 
intermediate and senior level [military] schools could have 
programs that give them basic information about Marine Corps 
[C2] architecture. Additionally, schools could request 
applications programs to enable students to validate their 
solutions to school exercises in the area of [C2] 
supportabili ty . 

6 . Others 



. . . . the [LFICS] information base could serve a wide 

variety of uses. Its utility could be extended by incor- 
porating ports to other information bases (e.g., JINTACCS) 
to access information on a wide variety of matters. Its 
usefulness is really limited only by our imagination and 
ingenuity . 

The general concept of the LFICS program of designing 
communications systems based on mission requirements was an 
excellent idea. According to Pipho [Ref. 1] the key to the 
LFICS program success will be: 

. . . an extensive analysis of the [C2] information require- 

ments. Once these requirements have been identified and 
verified, they can be matched with various sets of equipment 
to determine the effectiveness and efficiency of a particular 
[C2] architecture. 

However, several attempts were made to implement a 
LFICS architecture, but they were unsuccessful. Phipho states 
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that the "failure of earlier attempts was that each [attempt 
drove] the model [LFICS architecture] by equipment 
specifications rather than information requirements." Also, 
system planners for LFICS began to focus on communication 
needs, rather than on the basic issues of C2. [Ref. 1] 

So, after nearly 20 years, the Marine Corps still does 
not have a satisfactory information base with which it can 
effectively plan the acquisition of new communication systems 
which support a C2 architecture. [Ref. 1: p. 1] 

C. RELATED WORK 

The foundation of this thesis is the related work of two 
major efforts. One effort is the Marine Corps’ approach to 
resolving the problem of interoperability. A significant part 
of this effort was from the results of Major Pipho’s work 
[Ref. 2]. The other work evolved from a series of workshops 
sponsored by MITRE Corporation, the Military Operations 
Research Society (MORS), and most recently the Naval 
Postgraduate School (NPS) series of workshops held during the 
period February 1984 to January 1987 concerning C3 measurement. 

1 . Marine Corps’ Approach 

Major Pipho has proposed a tool to resolve the problem 
of interoperability management. His approach to this dilemma 
is to first simplify the concept of command and control in 
order to have a better understanding of the basic issues of 
interoperability. Secondly, he provides a baseline concept 
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for the design and implementation of a command and control 
integrated information base that will contain the necessary 
information required to effectively manage interoperability. 
[Ref. 2] A discussion of the fundamental structure of C2 
architectures is provided for a basic understanding of Pipho’s 
wor k . 

a. Introduction 

A command and control architecture is composed 
of one or more message exchange occurrences (MEOs) operating 
together to support the commander in the accomplishment of 
his mission. Pipho defines a MEO to be: ”A unique association 

of four essential components that define information transfer 
at the fundamental level. These components are source command 
and control element (C2E), sink, message standard, and C2E link 
standard." (See Figure 2.5) A C2E consists of equipment, 
communication, facilities, personnel, and procedures which 
perform the tasks and functions of a C2 node. A message 
standard is "a discrete set of message elements that carry 
information between C2Es." A link standard is "a discrete set 
of technical specif icatons requirements that characterize the 
signal interface between two C2Es." A C2 node may consist of 
one or more C2Es. [Ref. 2] 

b. Fundamental Structure of C2 Architectures 

The simplest of C2 architectures consist of two C2 
nodes where each node is represented by a C2E. If the C2Es 
have an exchange of information over a link, with one C2E 



23 



always transmitting and the other only receiving, then the C2 
architecture can be defined by one MEO, (See Figure 2,5) The 
ability of two C2Es to exchange information with one another in 
the support of some mission defines their interoperability. 

This is true, because in order for two C2Es to be able to 
exchange information they both must be able to handle the same 
discrete set of message elements that carry information between 
them and the same set of technical specifications requirements 
which enables this exchange of information. Therefore, the 
MEO, the simplest of C2 architectures, is the basic unit of 
interoperability. [Ref. 2] 

Pipho suggests that a MEO identifies the 
interoperbili ty requirements of larger and/or more complex 
architectures. Architectures which are more complex can be 
designed by interconnecting MEOs having a common C2E which 
supports the same mission. (See Figure 2.5). Pipho makes the 
following comment concerning interoperability of a C2 
architecture : 

An [architecture] that consists of a chain of validated MEOs 
necessarily reflects the compatibility and interoperability 
inherent in the MEOs that created it. This frees the user 
from concern about the validity of . . . interoperability in 
his C2 [architecture]. Instead, he [the user] may concentrate 
fully on the flow of command and control. [Ref. 2: p. 5] 

The validation of a MEO can be accomplished by verifying that 

it exists at some point in time according to doctrine and/or 

from the experience of experts in the field. Once MEOs have 

been validated for a given mission area, they could be recorded 
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A GENERIC EXAMPLE 




A SPECIFIC EXAMPLE 



Figure 2.5. A Message Exchange Occurence (MEO) . 
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into an integrated information data base for future reference. 
C2 planners and designers could use such a data base to study 
the implementation of potential C2 architectures. [Ref. 2] 

This integrated data base would necessarily contain the 
interoperability standards for any C2 architecture designed 
from the validated MEOs that are recorded in the data base. 

This data base would be similar to the one proposed for the 
LFICS program. (See Figure 2.4) 

Information exchange requirements are reflected in 
MEOs. However, there may be times when information that is 
required to support a task can not be passed. Perhaps the 
C2Es, link standard, and/or message type are not available in 
the appropriate arrangement to facilitate an exchange of infor- 
mation. Pipho suggests that an integrated information base 
could assist C2 planners in solving this problem. [Ref. 2] 

The first step toward developing the integrated 
information base is to identify the set of basic components 
that define the C2 architecture. At the most general level, 
these are: 

- C2Es 

- C2E tasks 

- C2E resources 

- Information required to perform C2E tasks 

- Communication capabilities to support the exchange of 
information 
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The relationship of these C2 components is 
important. Figure 2.6 displays the basic C2 components and 
their relationship. Resources of a C2E perform tasks. Tasks 
can be decomposed into subtasks that describe what activities 
the C2E is required to perform. In order to accomplish the 
defined tasks or subtasks, information is required to provide 
knowledge about the tasks. Information is of little value if 
it is not shared quickly by those who need to act upon it. So, 
information is exchanged by some form of communications. 

[Ref. 2 : p . 8 ] 

Resources can be grouped into two general 
categories, people and equipment. Pipho inferred that the 
degree of automation employed by a C2E is represented in the 
utilization of one type of resource over the other. The more 
equipment used to accomplish a task the greater the automation. 
Figure 2.7 illustrates the point that a C2E can have two types 
of resources. Personnel perform personnel tasks. The person- 
nel to perform these tasks require some knowledge about the 
task. This knowledge is contained in information elements. 
Information elements are then grouped into a message for an 
exchange of information. Equipment resources follow a similar 
process. Equipment tasks are performed by equipment and/or 
systems of equipment. Signals (mechanical or electrical) pro- 
vide equipment /systems of equipment some form of information so 
that they can perform equipment tasks. However, the signals 
must communicate over a circuit. The ability of a C2E to 
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exchange information with another C2E displays its ability to 
interoperate. [Ref. 2: pp. 5-7] 

Another approach to viewing the components of a C2E 
is depicted in Figure 2.8. The C2E components (resources, 
tasks, information, and communications) have some degree of 
interdependence. An increase in either the number of tasks, 
level of information, or amount of communications will demand 
larger quantities of resources to perform a particular func- 
tion. This increase in resources is captured in the resource 
curve. This curve is for illustrations purposes only. The 
actual slope of the resource curve will depend on the scenario. 
Intuitively, it is believed that the resource curve will always 
be mono tonically increasing. 

The characteristics of the C2E components deter- 
mine how a MEO will be defined; recalling that a MEO is 
defined by a source C2E, sink C2E, message standard, and link 
standard. The MEO is the basic unit of interoperability and is 
the foundation on which a C2 architecture should be designed. 
How MEOs are derived to design an implementation of a potential 
C2 architecture is the underlying focus of this thesis. The 
methods proposed in the workshop series will be employed to 
provide some insights into the interoperability problem. 

2 . Workshop Effort 
a. Introduction 

The series of workshops focused on an evaluation 
structure based upon measures of effectiveness (MOEs), which 
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Figure 2.8. Relationship of C^E Components. 
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would assist analysts and decision makers in their efforts to 
evaluate command and control systems in terms of improved 
combat effectiveness. [Ref. 3: p. iii] 

The workshop series resulted in an evaluation- 
formulation tool, which later became known as the Modular 
Command and Control Evaluation Structure (MCES). MCES is 
composed of seven separate modules that guide the analyst 
through a C3 evaluation, as illustrated in Figure 2.9. [Ref. 
8] Below is a brief description of the MCES methodology, 
b. MCES’ Methodology 

( 1 ) Module One (Problem Formulation) 



Module one, the problem formulation block, addresses the 
question of the decision maker’s needs and objectives in a 
specific problem. For a military sytstem, these could 
include the concept definition and development, system 
design, acquisition, or operations. This module is 
analogous to the systems approach ’’objectives of the 
system. . . . those goals or ends toward which the system 

tends.” The objectives need to be identified as ’’real” 
goals or ’’stated” goals, and once identified, need to be 
operationalized. [Ref. 7] 

( 2 ) Module Two (C2 System Bounding) 

Module two is the system bounding block and is used for 
identifying relevant quantities, including physical entities 
and structure, and boundaries of the subsystem, system, own 
forces, environment and reset of the world. Figure 2.10 
depicts the ’’onion skin” that describes the MCES systems 

bounding [Module two] includes everything outside the 

system’s control [the environment] and everything that deter- 
mines how the system performs. [Ref. 7] 

( 3 ) Module Three (C2 Process Definition) 

Module three, the process definition module, takes a given 
system configuration (i.e., a specific scenario and mission) 
and defines the processes needed to fulfill the mission. It 
maps the processes needed to fulfill the mission. It maps 
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Figure 2.9. Modular Command and Control Evaluation Strucure (MCES) . 
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Figure 2.10* Onion Skin Concept. 
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the processes needed to a Lawson-like loop system configura- 
tion. The concept focuses attention on the environmental 
” initiator,” the internal process function, and the input to 
and output from the internal process and environment, 
including enemy forces, own/neutral forces and usual 
environmental components. [Ref. 7] (This concept is 
explained in Chapter III). 

(4) Module Four (Integration of System Elements 
and Functions) 

Module four, the integration of statics and dynamics module, 
relates the information flow and process functions to the 
organizational structure as well as relating the physical 
entities ot the process functions. [Ref. 7] 

( 5 ) Module Five (Specification of Measures) 

[Module five is the specification of measures]. Guidelines 
are provided to identify, develop and select measures that 
gauge the C2 system’s response. These measures will provide 
a standard for comparison as the underyling architecture of 
the C2 system is reconfigured; they are directly tied to 
operational issues relating to the archtiec t ure. [Ref. 8] 

( 6 ) Module Six (Data Generation) 

Given that measures have been selected, the sixth module 
identifies the need to develop a data generator that will 
provide values for the C2 system’s response. [Ref. 8] 

Module six encompasses data generation by exercise, 
simulation, experiment, and/or subjective judgements. 

[Ref. 7] 



( 7 ) Module Seven (Aggregation of Measures) 

In the seventh module, techniques are provided to aggregate 
measures in a way that relates measurement of C2 response to 
combat outcome. [Ref. 8] 

The decision maker has several options after 
progressing through the seven modules. The options are do 
nothing, implement results, or make another iteration through 
one or more of the seven MCES modules. [Ref. 9] 
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The author will integrate the conceptual model 
of MCES with the MEO concept in order to provide some insight 
into how to address interoperability problems on an architec- 
tural level. 
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Ill . EXPANSION OF MCES FOR INTEROPERABILITY ANALYSIS 



A, INTRODUCTION 

This chapter serves to demonstrate the application of MCES 
as a tool to assist C2 managers and planners to better define 
interoperability requirements of C2 communications architectures 
through improving their ability to manage the sort of inter- 
operability problems addressed in Chapter II, Section B titled 
"HISTORICAL PRECEDENCE FOR THE WORK." 

In this MCES application, Pipho^s concept of a MEO will be 
added as the major tool for interoperability analysis. The MEO 
is considered to be the basic building block for C2 
communications architectures and the fundamental unit of 
interoperability. This concept will be further expanded by the 
author . 

B. BACKGROUND 

The author first attempted to apply Pipho’s concept of a 
MEO as described in Pipho’s paper titled "Cutting the Gordian 
Knot of Interoperability: A Sy stems-Engineered Solution to the 

Problem of Interoperability Modeling" [Ref. 2] to an air 
defense C2 architecture. The author used the Marine Corps^ 
"Technical Interface Concepts for Marine Tactical Systems," 
otherwise known as the "TIC" to verify Pipho^s claim. 
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[The TIC] . . . establishes Marine Corps interoperability and 

intraoperability requirements. In these areas, it provides 
planning guidance for true specification and development of 
Marine Corps tactical data systems, equipments, and procedures. 
[Ref. 10; p. 1 ] 

The following is quoted from the TIC concerning 

information exchange requirements: 

Information exchange requirements were developed from 
approved doctrine, existing standing operating procedures, 
and established techniques played against a scenario 
depicting Marine Corps units in . . . amphibious and land 
combat operations. These requirements were further 
categorized and correlated with the broad operational tasks 
and information categories of JCS Pub 12, providing two-way 
traceability between defined agency [OPFAC] tasks and the 
broad operational tasks.” [Ref. 10: pp. 1-2] 

From the above quote, the TIC should be able to support 

Pipho’s MEO approach to designing a C2 architecture. But the 

author found that it does not as described below. 

The author defined the archecture C2Es as shown in Figure 

3.1 for an air defense scenario. The air-defense system was 

defined by the following control facilities/agencies: 

- Tactical Air Control Center (TACC) 

- Tactical Air Operations Center (TAOC) 

- Light Antiaircraft Missile Battery (LAAM) 

- Forward Area Air Defense Battery (FAAD) 

- Combat Air Patrol (CAP) 



1 

Intraoperability is equivalent to interoperability except 
that intraoperability is concerned with operations within one 
system, whereas interoperability is focused on operations 
between different systems. 



2 

The TIC refers to the C2E concept as an operational 
facility (OPFAC) [Ref. 14: p. 2-1] The terms C2E and OPFAC 

will be used interchangeably in this chapter. 
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Figure 3.1. An Air Defense Organization. 
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He then proceeded to identify the information exchange 
requirements between C2Es without much success. Although the 
basic ideas supporting the MEO concept are there, the descrip- 
tion of the tasking of OPFACs is not appropriate. There is no 
definitive way to implement the resultant exchange information 
exchange requirements. The author found it impossible to iden- 
tify what type of information had to be exchanged between C2Es 
using the TIC. Therefore, the author was unable to build MEOs 
and consequently he was also unable to design an air defense 
architecture from the TIC alone. 

The OPFAC tasks were not logically organized. An OPFAC task 
consists of a five digit number. The first three digits 
represents a particular OPFAC, i.e., OPFAC #650 (TACC) (See 
Appendix A). The last two digits identify a functional area 
category (See Appendix B). Numbers were assigned to OPFAC 
tasks without regard to operational considerations; such as the 
force level (company, battalion, or division) or the interrela- 
tionships of tasks. 

The narrative summaries in the TIC associated with the 
OPFAC tasks do not allow distinguishing between hierarchical 
levels, e.g., MAU vs MAF, or between specific mission areas, 
such as anti-air warfare and land combat operations. This 
made it impossible to apply Pipho^s MEO approach to analyze 
interoperability requirements, at the appropriate level and for 
designated missions from the TIC. Therefore, an additional 
technique as described in the next section was developed. 
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C. DESCRIPTION OF PROBLEM 

Recalling that a MEO is defined by a source C2E, sink C2E, 
a message standard, and a link standard, the author expanded 
the TIC’s approach to interoperability management requirements. 
In order to define a MEO, its four elements must be identified 
in terms of their characteristics. First both source and sink 
C2Es are determined. These are very easy to characterize, 
while the remaining two elements of a MOE are not. The message 
standards are dependent on what type of tasks are being per- 
formed. However, all too frequently, the tasks to be performed 
are neither well delineated nor well documented. Since tasks 
are often difficult to define, message standards, which depend 
on task definitions, are subsequently difficult to charac- 
terize. Link standards, in turn, are dependent on message 
standard characteristics. The relationship between C2Es and 
tasks can be analogous to a sentence structure diagram (See 
Figure 3.2). The C2Es can be considered to be similar to 
subject/object which are the ’’doers"; while the task can be 
equated to a verb, which describe the action between the C2Es. 
[Ref. 11] 

A C2E can be characterized by its (1) nation, (2) service, 
(3) branch, (4) echelon, and (5) unit. The following is an 
example: Communications Support Company, Eight Communications 
Battalion, Force Service Support Group, Fleet Marine Force 
Atlantic, United States of America. If the unit is unique and 
one is familar with it, one may also know the identify of its 
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2 

Figure 3.2. C E and Task Structure. 
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echelon, branch, service, and nation; such as in the example: 
Communication Support Company is unique to the U.S. Marine 
Corps and the Eight Communications Battalion, so the other 
organizational levels are implicitly known. A unit has certain 
resources (equipment and personnel) which further characterizes 
a C2E. [Ref. 11] 

Task or OPFAC task are not as easily characterized. The 
TIC is a first attempt at task specification; however, as 
indicated previously, its approach is not refined enough to meet 
this challenge. The narrative summaries defining OPFAC tasks 
are too broad. They address several tasks which makes it very 
difficult to identify what is actually being done and what 
information requirements are associated with a given task. 

Also, if one could identify the information requirements needed 
to develop message standards for a collection of MEOs, they 
most likely could not work backwards. That is, given an MEO, 
what task is associated with it? The narrative summary for 
OPFAC task 65001 (TACC) is provided to illustrate the above 
point . [ Ref . 11 ] 

TACC Task 67500. Supervise and coordinate the operational 
planning and tactical execution thereof by subordinate and 
supporting agencies to preserve economy and unity of effort, 
while ensuring the accomplishment of the missions of the TACC 
in support of the MAGTF objectives; modify the tasking of 
supporting agencies as required. [Ref. 10: p. D-2] 

Examining the above narrative, it is very difficult to tell 

where one task ends and another begins. Also, it is impossible 

to determine what organizational level this summary is 
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referring to. However, assuming there is an MEO defined for one 
of the tasks contained in the above summary, it would be very 
difficult, if not impossible, to tell what task the MEO is 
related to . 

Using the MCES structure, the author synthesized the above 
approaches to characterizing C2Es to respond to the analytic 
challenge of characterizing tasks. 

1 . Problem Formulation 

There are two foci in this thesis, (1) operational 
considerations and (2) methodological issue. 

a. Operational Considerations 

After their attempt to design an air defense C2 
architecture using the TIC, both the author and Pipho agreed 
that the methodology set forth in the TIC should be examined 
and analyzed for its ability to adequately address 
interoperability problems on an architectural level. This was 
undertaken by employing, as a test case, the OPFAC tasks 
associated with a C2 communications architecture that is 
required to produce an air tasking order (Frag). 

b. Methodological Issue 

Conversely, by examining the procedures associated 
with the air tasking order, this thesis will verify the ability 
of a Lawson-like C2 Process model to practically describe 
service doctrine. 
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2 . C2 System Bounding 

The physical entities of the C2 communications 
architecture are the Combat Operations Center Marine Air-Ground 
Task Force (COC MAGTF), Combat Operations Center Ground Element 
(COC GE), and Tactical Air Command Center (TACC), (See Figure 
3.3) These three OPFACs are the C2Es of a Marine Amphibious 
Brigade (MAB), The COC GE and TACC are considered to be on the 
same organizational level, although the TACC supports the COC 
GE with air support requirements. Each of the C2Es are 
commanded by a commander who is supported by a staff. The 
commander of the COC MAGTF is called the MAGTF commander or MAB 
commander, but for this thesis the MAGTF commander title will 
be used. The COC GE is commanded by the Ground Combat Element 
Commander (GCE) who is responsible for identifying, planning, 
and establishing target priorities and coordinating the air 
attacks as directed by the MAGTF commander [Ref. 12: p. 1-4]. 

The ACE commander has the authority to plan, control, and 
coordinate all air operations within his assigned area [Ref. 

12: p. 1-4]. Both the GCE commander and ACE commander report 
directly to the MAGTF commander who is in charge of the overall 
combat operation. 

The bounding process also specifies the physical 
relationship of C2Es. Although this C2 communications 
architecture is organized to employ the doctrine of centralized 
control, the physical entities are by doctrine distributed 
physically. (See Figure 3.4) In one typical scenario, the 
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Figure 3.3. Organizational Structure for a MAGTF . 
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Figure 3.4. A Typical Geographic Arrangement of a MAGTF. 



TACC is located ten miles north and five miles west of the COC 



MAGTF, while the COC GE is located five miles north and 
fifteen miles east of the COC MAGTF. This geographic 
separation is a consideration when defining interoperability 
requirements of communications systems. Essential 
interoperability requirements are depicted in Figure 3.5a, 
while intraoperability requirements within an OPFAC are 
illustrated in Figure 3.5b. 

3 . C2 Pr ocess Definition 



a. Marine Air-Ground Task Force 

The Marine Air-Ground Task Force (MAGTF) is a force of 
combined arms task organized for a specified mission. The 
MAGTF may be employed in an amphibious operation or a land 
campaign. In either concept of employment the MAGTF is task 
organized to exploit the combat power inherent in closely 
integrated air and ground forces. [Ref. 12: p. 1-1] 

For the purposes of this thesis, the author only considered the 
ACE commander plus his immediate staff working in the TACC as 
the air component, as well as the GCE commander plus his imme- 
diate staff, manning the COC GE, as the ground component force. 
So, the MAGTF for this problem consisted of the TACC and COC GE 
under the direction of the MAGTF commander. 

( 1 ) Ground Combat Element Commander (GCE) 

[The GCE commander is responsible to the MAGTF commander]. 
Through target analysis and his assigned mission objectives, 
the GCE commander recommends the apportionment and alloca- 
tion of offensive air support. The GCE commander decides 
by priority which targets require interdiction by aviation. 
While selecting targets for air interdiction, the GCE 
commander receives and estimate of aviation support 
required to atack these targets and, by subtraction, deter- 
mines how many remaining air assets will be available for 
close air support. Once the air interdiction targets are 
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Figure 3.5a. Essential Interoperability Requirements 
for Air Tasking Order. 
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Figure 3.5b. Intraoperability Requirements Within an 
OPFAC . 
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identified, the MAGTF commander approves the offensive air 
support apportionment and allocation. The GCE commander must 
now decide how much of the remaining air assets to use for 
preplanned CAS [close air support] missions, and how much, if 
any, to place in an appropriate alert condition for immediate 
CAS missions. [Ref. 12: p. 1-4] 

( 2 ) Aviation Combat Element Commander (ACE) 

The ACE commander commands a supporting force the ”air 
arm.” Within the division of authority, the ACE commander is 
responsible to the MAGTF commander for analyzing all aspects 
of antiair warfare, formulating an antiair warfare concept to 
include offensive and defensive requirements, and presenting 
the concept for approval. The ACE commander also provides 
the ground combat element commander (GCE) with an estimate of 
the aviation capability that can be applied to the remaining 
function offensive air support. [Ref. 12: p. 1-4] 

The aviation combat element of the larger MAGTF’s normally 
possesses diverse employment capabilities. However, 
considering the threat that the MAGTF will likely face, 
planning for the effective employment of its tactical air arm 
is not a simple matter. The MAGTF relies heavily on its 
aviation force, and every effort must be made to insure its 
most effective employment. In ”target rich” environments, 
tactical air resources will rarely be sufficient to meet 
demand. [Ref. 12: p. 1-1] 

Therefore, it is paramount that the air tasking process be well 
defined in terras of functional requirements. 

( 3 ) Aviation Tactical Functions 

The aviation combat element is task organized to provide the 
required functional air requirements of the MAGTF. The 
functions of principal concern to the air tasking process are, 
(1) antiaiar warfare, (2) offensive air support, and (3) air 
command and control. A firm knowledge of these functions and 
types of targets associated with each is the most important 
requirement for understanding the air tasking process. [Ref. 

12: p . 1 - 1 ] 

Figure 3.6 graphically depicts the air tasking process as done 
in the Marine Corps according to the Operational Handbook (OH) 
5-3, Tasking USMC Fixed Wing Tactical Aviation .” [Ref. 12: 



Appendix A) ] 
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Figure 3.6. MAGTF Fixed Wing Air Tasking Process. 
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b. Mapping C2 Functions 

One of the MORS working groups provided a basic 
model that represents the basic arrangement of most C2 processes. 
This conceptual C2 model is shown in Figure 3,7. This model is 
generally characterized by six C2 process functions which have a 
direct or indirect influence on the friendly (own) forces 
operating in the environment. [Ref. 3: p. 5-3] 

( 1 ) Definitions of Functions 



The six C2 process functions as defined in the 
text titled Command and Control Evaluation Workshop [Ref. 3 : 
p. 5-5] are quoted below: 

Sense--That function which collects data necessary to 
describe and forecast the environment, which includes: 

- The enemy forces’ disposition and actions. 

- The friendly forces’ disposition. 

- Those aspects of the environment that are common to both 
forces, e.g., weather, terrain, and neutrals. 

Assess--That function which transforms data from the 
function into information about intentions and capabilities 
for enemy forces and about capabilities of friendly forces 
for the purpose of determining if division from the Desired 
States warrants further action. 

Genera te--Tha t function which develops alternative courses 
of action to correct deviations from the Desired State. 

Select--That function which selects a preferred alternative 
from among the available options. It includes evaluation of 
each option in terms of criteria necessary to achieve the 
Desired State. 

Plan--That function which develops implementaton details 
necessary to execute the selected course of action, 

Direct--That function which distributes decisions to the 
forces charged with execution of the decision. 
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Figure 3.7. Lawson-Like C Process Model. 
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( 2 ) Description of C2 Process 



A single OPFAC performing a single isolated 
task, which requires no interaction or feedback considerations, 
can be modeled by Figure 3 . 1 . [Ref. 3: p. 5-5] This C2 

process is summarized below: 

. . . there are interactions with the environment. These 

interactions are represented by a stimulus input and a 
response output. The output can only cause and action 
through our own forces, which results in a change to the 
overall environment. External inputs are shown coming from 
the environment and are susceptible to both natural and 
human-initiated environment effects. The only other direct 
input to the process, the desired State, establishes an error 
function inside the loop. This error function causes 
processing activity to continue, or, at the other extreme, 
halts processing activity when the Desired State is believed 
to be reached. [Ref. 3: pp. (5-3) - (5-5)] 

The process is initiated when a sensed input is assessed 
and is determined or is believed to be in error with a 
Desired State or when our requirements for the Desired State 
change. These errors cause the generation and selection of 
options, which results in a plan intended to change the 
environment. The object is to minimize the difference 
between the assessed and desired environment. [Ref. 3: p. 5-5] 

The C2 process involving the COC MAGTF, COG GE, and TACC 

OPFACs producing an air tasking order is much more complicated 

than the process described above. This point will be addressed 

further in the following section. 

c. Application of Air Tasking Order 

Relying on doctrinal and operational experience, 

the author mapped the C2 functions to the tasks required 

to produce an air tasking order. The flow chart in 



3 

The air tasking order tasks were obtained from the 
Operational Handbook (OH) 5-3, Tasking USMC Fixed Wing 
Tactical Aviation , Appendix A. 
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Figure 3.6 (the shaded rectangles) provides a graphical mapping 
of the C2 process functions to the tasks, while in Table 3.1 a 
tabular mapping is presented. Mapping C2 functions to tasks 
was not straightforward. As can be seen from the graphical 
mapping of C2 functions to tasks in Figure 3.6, the C2 functions 
do not follow a sequential flow as depicted in Lawson-like 
conceptual model in Figure 3.7. 

A single OPFAC for the air tasking order is better 
represented by the conceptual model designed by the author in 
Figure 3.8. This model designed by the author is the same as 
the one in Figure 3.7, except that it includes feedback options 
for each function. An OPFAC does not have to progress sequen- 
tially from the ^’sense” function through to the "direct” 
function. This is evident as seen in the flow chart of Figure 
3.6. Theoretically there are an infinite number of ways that 
an OPFAC can perform the functions to control its own forces. 
This model is fine for a single OPFAC working autonomously; 
however, three OPFACs interacting together are required to 
produce an air tasking order. Figure 3.8 is inadequate to 
model the coordination among three independent OPFACs. 

In Figure 3.9 the author expanded the func- 
tional feedback option concept to the hierarchical-interactive 
relationship of the COC MAGTF, COC GE, and TACC. The princi- 
ples of operation for the model in Figure 3.9 are identical to 
that of the model in Figure 3.8, with two additional main 
points: (1) the COC MAGTF establishes the Desired State for 
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TABLE 3.1 



PROCESS FUNCTIONS MAPPED TO AIR 
TASKING ORDER TASKS 



TASK 

NUMBER 


TASK 

DESCRIPTION 


C^ FUNCTIONS 


1 


1 . 1 


MAGTF CDR ISSUES 
APPORTIONMENT GUIDANCE 


DIRECT 


1 


1 .2 


MAGTF CDR ISSUES 
APPORTIONMENT GUIDANCE 


DIRECT 


2 


1 . 1 


ACE CDR ISSUES 
PLANNING GUIDANCE 


ASSESS 


2 


1.2 


ACE CDR ISSUES 
PLANNING GUIDANCE 


DIRECT 


2 


2. 1 


ACE/MAGTF DEVELOP 
OFFENSIVE AAW TARGETS 


ASSESS 


2 


2.2 


ACE/MAGTF DEVELOP 
OFFENSIVE AAW TARGETS 


GENERATE 


3 


1 . 1 


ACE DEVELOP DEFENSIVE 
AAW REQUIREMENTS 


ASSESS 


3 


1 .2 


ACE DEVELOP DEFENSIVE 
AAW REQUIREMENTS 


GENERATE 


3 


2.1 


ACE INTEGRATES 
OFFENSIVE AND DEFENSIVE 
AAW REQUIREMENTS INTO 
AAW CONCEPT 


SELECT 


3 


2.2 


ACE INTEGRATES 
OFFENSIVE AND DEFENSIVE 
AAW REQUIREMENTS INTO 
AAW CONCEPT 


PLAN 
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TABLE 3.1 



c2 PROCESS FUNCTIONS MAPPED TO AIR 
TASKING ORDER TASKS (CONTINUED) 



TASK TASK Co FUNCTIONS 

NUMBER DESCRIPTION 



3 3.1 ACE CALCULATES SORTIES ASSESS 

REQUIRED FOR AAW AND 
AVAILABLE FOR OAS 

3 3.2 ACE CALCULATES SORTIES GENERATE 

REQUIRED FOR AAW AND 
AVAILABLE FOR OAS 

3 3.3 ACE CALCULATES SORTIES SELECT 

REQUIRED FOR AAW AND 
AVAILABLE FOR OAS 

3 3.4 ACE CALCULATES SORTIES PLAN 

REQUIRED FOR AAW AND 
AVAILABLE FOR OAS 



4 


1 . 1 


GCE ISSUES 
GUIDANCE 


PLANNING 


ASSESS 


4 


1 .2 


GCE ISSUES 
GUIDANCE 


PLANNING 


DIRECT 


4 


2.1 


GCE PREPARES INITIAL 


ASSESS 



ESTIMATES OF CLOSE 

AIR SUPPORT REQUIREMENTS 



4 2.2 GCE PREPARES INITIAL GENERATE 

ESTIMATES OF CLOSE 
AIR SUPPORT REQUIREMENTS 



5 1.1 GCE DEVELOP AND PRIORITIES SELECT 

AIR INTERDICTION TARGETS 
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TABLE 3.1 



PROCESS FUNCTIONS MAPPED TO AIR 
TASKING ORDER TASKS (CONTINUED) 



TASK TASK C2 FUNCTIONS 

NUMBER DESCRIPTION 



5 1.2 GCE DEVELOP AND PRIORITIES PLAN 

AIR INTERDICTION TARGETS 



6 1.1 MAGTF CDR CONVENES DIRECT 

APPORTIONMENT CONFERENCE 

6 1.2 MAGTF CDR CONVENES DIRECT 

APPORTIONMENT CONFERENCE 



7 1.1 ACE BRIEFS AAW CONCEPT GENERATE 

AND ALTERNATIVES EFFECTING 
OAS CAPABILITY 



7 2.1 DOES THE AAW CONCEPT SELECT 

REQUIRE MODIFICATION 

7 2.2 DOES THE AAW CONCEPT ASSESS 

REQUIRE MODIFICATION 



7 3.1 MAGTF CDR PROVIDES DIRECT 

GUIDANCE FOR MODIFICATION 
OF AAW CONCEPT 

7 11.1 ACE MODIFIES AAW CONCEPT ASSESS 

AND COMPUTES SORTIES 
AVAILABLE FOR OAS 

7 4.2 ACE MODIFIES AAW CONCEPT GENERATE 

AND COMPUTES SORTIES 
AVAILABLE FOR OAS 
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TABLE 3.1 



PROCESS FUNCTIONS MAPPED TO AIR 
TASKING ORDER TASKS (CONTINUED) 



TASK TASK C^ FUNCTIONS 

NUMBER DESCRIPTION 



7 4.3 ACE MODIFIES AAW CONCEPT SELECT 

AND COMPUTES SORTIES 
AVAILABLE FOR OAS 

7 4.4 ACE MODIFIES AAW CONCEPT PLAN 

AND COMPUTES SORTIES 
AVAILABLE FOR OAS 



8 1.1 MAGTF CDR APPROVES SELECT 

THE AAW PLAN 



9 1.1 MAGTF CDR APPROVES THE SELECT 

APPORTIONMENT AND ALLOCA- 
TION OF AAW AND OAS 



10 1.1 GCE DETERMINES AIR INTER- SELECT 

DICTION TARGETS TO BE 
ATTACKED WHILE CONSIDER- 
ING THEIR COST AMD THAT 
CAPABILITY WHICH REMAINS 
FOR CAS 

1C 1.2 GCE DETERMINES AIR INTER- ASSESS 

DICTION TARGETS TO BE 
ATTACKED WHILE CONSIDER- 
ING THEIR COST AND THAT 
CAPABILITY WHICH REMAINS 
FOR CAS 



10 2.1 MAGTF COMMANDER APPROVES SELECT 

AND/OR MODIFIES THE AIR 
INTERDICTION 



61 



TABLE 3.1 



PROCESS FUNCTIONS MAPPED TO AIR 
TASKING ORDER TASKS (CONTINUED) 



TASK TASK C^ FUNCTIONS 

NUMBER DESCRIPTION 



10 2.2 MAGTF COMMANDER APPROVES GENERATE 

AND/OR MODIFIES THE AIR 
INTERDICTION 



11 1.1 MAGTF CMD APPROVES THE PLAN 

APPORTIONMENT AND ALLOCA- 
TION OF AIR INTERDICTION 
AMD CAS 

11 1.2 MAGTF CMD APPROVES THE DIRECT 

APPORTIONMENT AND ALLOCA- 
TION OF AIR INTERDICTION 
AND CAS 



12 1.1 GCE SUBMITS AIR INTERDIC- SELECT 

TION TARGETS BY PRIORITY 
TO ACE FOR TASKING 



13 



DOES THE MAGTF REQUIRE ASSESS 

ADDITIONAL AIR SUPPORT 
ASSETS FOR AIR INTERDIC- 
TION? 



13 2.1 



ACE IDENTIFIES ADDITIONAL GENERATE 
AIR SUPPORT REQUIREMENTS 
FOR AIR INTERDICTION 
TARGETS 



13 2.2 



ACE IDENTIFIES ADDITIONAL GENERATE 
AIR SUPPORT REQUIREMENTS 
FOR AIR INTERDICTION 
TARGETS 
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TABLE 3.1 



PROCESS FUNCTIONS MAPPED TO AIR 
TASKING ORDER TASKS (CONTINUED) 



TASK TASK C^ FUNCTIONS 

NUMBER DESCRIPTION 



13 3.1 GCE CDR DETERMINES CAS ASSESS 

ALLOTMENT TO INCLUDE THE 
PREPLANNED AND IMMEDIATE 
MIX 

13 3.2 GCE CDR DETERMINES CAS SELECT 

ALLOTMENT TO INCLUDE THE 
PREPLANNED AND IMMEDIATE 
MIX 



14 1.1 GCE UNITS CONDUCT DETAILED PLAN 

FIRE SUPPORT AMD SEAD PLAN- 
NING 



14 2.1 GCE CDR APPROVES TAR'S PLAN 

W/SEAD REQUIREMENTS AMD 
SUBMITS TO ACE FOR TASKING 

14 2.2 GCE CDR APPROVES TAR'S DIRECT 

W/SEAD REQUIREMENTS AND 
SUBMITS TO ACE FOR TASKING 



15 1.1 ACE DETERMINES CAS REQUIRE- ASSESS 

MENTS 



15 2.1 ACE INITIATES PREPARATION GENERATE 

OF THE AIR TASKING ORDER 
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TABLE 3.1 



PROCESS FUNCTIONS MAPPED TO AIR 
TASKING ORDER TASKS (CONTINUED) 



TASK TASK C^ FUNCTIONS 

NUMBER DESCRIPTION 



15 3.1 DO OAS REQUIREMENTS EXCEED ASSESS 

MAGTF A/C AVAILABLE? 

15 3.2 DO OAS REQUIREMENTS EXCEED ASSESS 

MAGTF A/C AVAILABLE? 



15 4.1 GCE MODIFIES IMMEDIATE- ASSESS 

PREPLANNED MIX ASSISTED 
BY ACE 

15 4.2 GCE MODIFIES IMMEDIATE- ASSESS 

PREPLANNED MIX ASSISTED 
BY ACE 

15 4.3 GCE MODIFIES IMMEDIATE- GENERATE 

PREPLANNED MIX ASSISTED 
BY ACE 



15 5.1 GCE MODIFIES THE AIR- PLAN 

INTERDICTION-CAS MIX 
ASSISTED BY ACE/MAGTF 
(MAGTF APPROVES) 

15 5.2 GCE MODIFIES THE AIR- ASSESS 

INTERDICTION-CAS MIX 
ASSISTED BY ACE/MAGTF 
(MAGTF APPROVES) 



15 5.3 GCE MODIFIES THE AIR- GENERATE 

INTERDICTION-CAS MIX 
ASSISTED BY ACE/MAGTF 
(MAGTF APPROVES) 
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TABLE 3.1 



PROCESS FUNCTIONS MAPPED TO AIR 
TASKING ORDER TASKS (CONTINUED) 



TASK TASK C^ FUNCTIONS 

NUMBER DESCRIPTION 



15 5.4 GCE MODIFIES THE AIR SELECT 

INTERDICTIOK-CAS MIX 
ASSISTED BY ACE/MAGTF 
(MAGTF APPROVES) 



15 6.1 ACE MODIFIES AAW PLAN PLAN 

(MAGTF APPROVES) 

15 6.2 ACE MODIFIES AAW PLAN SELECT 

(MAGTF APPROVES) 



15 7.1 IS ADDITIONAL AIR ASSESS 

SUPPORT REQUIRED FOR 
AIR INTERDICTION OR 
CAS? 



15 8.1 ACE IDENTIFIES ASSESS 

ADDITIONAL AIR 
SUPPORT REQUIREMENTS 
FOR CAS-AND/OR AIR 
INTERDICTION 



15 9.1 ACE FORWARDS DIRECT 

ADDITIONAL AIR SUPPORT 
REQUIREMENTS TO MAGTF 
FOR JTF CONSIDERATION 



15 10.1 DOES MAGTF A/C AVAIL- ASSESS 

ABILITY EXCEED THE AIR 
SUPPORT REQUIREMENTS 
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TABLE 3.1 



C 



2 PROCESS FUNCTIONS MAPPED TO AIR 
TASKING ORDER TASKS (CONTINUED) 



TASK TASK C^ FUNCTIONS 

NUMBER DESCRIPTION 



15 11.1 ACE COMPUTES EXCESS GENERATE 

SORTIES AND FORWARDS 
TO MAGTF FOR CROSS- 
TASKING BY JTF 



15 12.1 ACE COORDINATES AND 

INTEGRATES ALL AIR 
SUPPORT REQUIREMENTS 



GENERATE 



15 12.2 ACE COORDINATES AND 

INTEGRATES ALL AIR 
SUPPORT REQUIREMENTS 



SELECT 



15 13.1 ACE DEVELOPS AND 

COMPLETES THE AIR 
TASKING ORDER AND 
DISTRIBUTES 



PLAN 



15 13.2 ACE DEVELOPS AND 

COMPLETES THE AIR 
TASKING ORDER AMD 
DISTRIBUTES 



DIRECT 



15 13.3 ACE DEVELOPS AND 

COMPLETES THE AIR 
TASKING ORDER AND 
DISTRIBUTES 



DIRECT 
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Figure 3.8. Lawson-Like Process Model Expanded. 
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Figure 3.9. Expanded process Model to Show Interaction 
Among Three Individual OPFACs. 
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the COC GE and TACC through Directions. Both the COG GE and 
TACC have the option to compare any point (C2 function) of the 
C2 processing to the Desired State; and (2) Each of the three 
OPFACs can have an interaction with another OPFAC during any 
point in the C2 process. 

4 . Integration of System Elements and Functions 

”The JINTACCS program has derived 12 categories of 
information exchange requirements among and between various 
OPFACs. When an individual information category is applied to 
each of the 12 operational tasks, the content of the category 
varies according to the task. This application refines the 
basic 12 information categories in defining information 
exchange requirements.” [Ref. 10: p. 3-5] The bounded system 

(OPFACs and the air tasking order tasks) coupled with the 
information category codes (ICC) (See Appendix C) provide the 
basis for the integration of system elements and functions. 

Table 3.2 portrays the integration of the OPFACs and tasks 
required to produce an air tasking order. The tasks in column 
2 are reproduced from the Tasking USMC Fixed-Wing Tactical 
Aviation , Operational Handbook. Then, using the cross-reference 
table for C2 functions to the ICC in Table 3.3, column 2 was 
completed. This cross-reference table was based on operational 
experience. Information from the environment concerning enemy 
status and friendly status is equivalent to describing the 
sense function. Analyzing the enemy capabilities and friendly 
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INTEGRATION OF SYSTEM ELEMENTS 
AND FUNCTIONS 
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INTEGRATION OF SYSTEM ELEMENTS 
AND FUNCTIONS (CONTINUED) 
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TABLE 3.2 

INTEGRATION OF SYSTEM ELEMENTS 
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AVAILABLE FOR OAS 



INTEGRATION OF SYSTEM ELEMENTS 
AND FUNCTIONS (CONTINUED) 
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ACE COORDINATES AND AL GCE STAFF ACE STAFF 65001 

INTEGRATES ALL AIR 601 650 

SUPPORT REQUIREMENTS 



INTEGRATION OF SYSTEM ELEMENTS 
AND FUNCTIONS (CONTINUED) 
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ACE DEVELOPS AND OR ACE CDR GCE CDR 65043,65001 

COMPLETES THE AIR 650 6OI 

TASKING ORDER AND 
DISTRIBUTES 



TABLE 3.3 



PROCESS FUNCTIONS CROSS-REFERENCED 
TO INFORMATION CATEGORIES 



C^ FUNCTION 


INFORMATION CATEGORIES 


SENSE 


ENEMY STATUS (ES) 
FRIENDLY STATUS (FS) 
WEATHER (WS) 


ASSESS 


ENEMY CAPABILITIES (EC) 
FRIENDLY CAPABILITIES (FC) 


GENERATE 


ALLOCATION /APPORTIONMENT 
(AL) 


SELECT 


PRIORITIES (PR) 


PLAN 


PLANS (PL) 


DIRECT 


ORDERS (OR) 

REQUEST FOR SUPPORT (RS) 
REQUEST FOR INFORMATION (RI) 
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capabilities is the same as assessing the situation. When a 
commander allocates, he is refining his apportionment decision. 
In consideration of the apportionment, the commander prepares 
the allocation by generating specific alternatives and making 
this process analogous to the generate function. When the 
commander assigns priorities to his options he is selecting 
among his alternatives, which is similar to the select 
function. The plans category is straightforward and relates 
directly to plan function. Request for information, request 
for support and orders are results of a commander directing a 
specific response from a subordinate command; they are 
therefore equivalent to the direct function. 

Having cross-referenced the C2 functions to the ICC 
in Table 3.3, the author relied upon doctrine and his opera- 
tional experience to select the appropriate ICC for each task. 
Columns 4 and 5 of Figure 3.2, the transmitting OPFAC (XOPFAC) 
and the receiving OPFAC (ROPFAC), were chosen by the tasks 
described. If the tasks statement mentioned the "ACE,^* then 
the TACC (OPFAC #650) would be considered as the source and/or 
sink. The MAGTF commander would correspond to the COC MAGTF 
(OPFAC #600) and the GCE would correspond to the COC GE (OPFAC 
#601). Again the author had to rely heavily on operational 
experience when determining the second OPFAC. The second OPFAC 
may or may not have been the same as the first. When both the 
XOPFAC and ROPFAC were the same, this implied intraoperability 
as opposed to interoperability. The final column titled ”0PFAC 
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task” was completed by comparing the first five columns to the 
OPFAC tasks narrative summaries contained in the TIC, and 
selecting the ”most" appropriate OPFAC task(s). Appendix A 
provides a narrative summary from each of the OPFAC tasks 
involved . 

5 . Specifications of Measures, Data Generation 
and Aggregation of Measures 

The last three MCES modules (Specification of Measures, 
Data Generation, and Aggregation of Measures) are beyond the 
scope of this thesis. However, the author recommends that 
remaining modules be developed further. 

D. ANALYSIS OF THE APPLICATION 

Recall that a MEO is defined by a unique arrangement of 
(1) source C2E, (2) Sink C2E, (3) message standard, and (4) 
link standard. The better the characterization of the 
components of a MEO, the easier it is to construct MEOs. The 
C2Es are easy to characterize by their descriptive elements 
(See Figure 3.2), but message standards are not. The 
application of this thesis provides some insight on how to 
refine and expand the characterization of tasks which determine 
message standards. 

The author has shown that the tasks associated with 
producing an air tasking order can be characterized in terms of 
(1) C2 functions, (2) information category codes, (3) C2Es, and 
(4) tasks associated with a C2E (OPFAC task) (See Table 3.2 and 
Figure 3.10). These characteristics of a task can be used to 
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Figure 3.10. Structure of C^Es and their Associated Task- 



90 



identify what type of information that is required to be 
exchanged between two OPFAC. C2 planners can use information 
requirements to define standardized message exchanges between 
two OPFACs, which define message standards. Once message 
standards are defined, C2 planners can decide what kind and how 
many data elements are required to adequately identify the 
information needed in the message standard. The number of 
data elements and the speed of which they must be exchanged 
between OPFACs would be used to define the link standard. The 
author has identified a more precise way to define the 
components of a MEO, which should be used to construct MEOs. 

Once all potential MEOs and their descriptive charac- 
teristics have been identified, coded and recorded in an 
integrated interoperability database (IIDB), C2 planners 
could use this vast amount of information to manage 
interoperability problems. For instance, a planner may want to 
know what communications equipment is required to support an 
air defense mission. He could enter the IIDB and ask for all 
MEOs associated with an air defense mission. Then he could 
request the communications equipment which could support the 
particular link standards associated with those MEOs. Or he 
may desire to know what tasks are performed within an air 
defense mission. If so, he would ask for the message standards 
of the MEOs associated with air defense. Then he would ask for 
the tasks relating to the message standard. Also, the C2 
planner could manage interoperability requirements by using the 
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IIDB and asking a question such as: given units "A," "B," "C/' 

and "D," what types of communications equipment is required to 
support them in a particular exercise and does all the equip- 
ment exist? And if not, given the available resources what 
MEOs are involved and what tasks can be supported? One can 
begin to see that almost any question about interoperability/ 
intraoperability can be addressed and answered using an IIDB, 
[Ref. 11] 
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IV. CONCLUSIONS AND RECOMMENDATIONS 



A. OPERATIONAL CONSIDERATIONS 

1 . Weaknesses 

The concept of defining interoperability and 
intraoperability requirements of C2 architectures in terms of 
MOEs is not a trivial matter. The actual method by which the 
Marine Corps and other services operate must be accurately 
verified and documented. Doctrinal publications are required 
to distinctly reflect the actual ways in which the services may 
operate. This effort will call for the services to think and 
plan in a broader perspective. They will have to reorganize 
their thinking in order to implement and adhere to a "truly" 
systematic approach when addressing operational considerations. 

2 . Strengths 

The overall concept of distinctly defining the tasks 
which are involved in operational missions is a sound idea. 

This concept will enable military commanders to train their 
force in a more realistic way. The services will have a better 
grasp on what things they can do and can not do. They will 
have a methodology that will permit them to view the tasks 
necessary to support an operation, along with the resources 
required. This methodology gives the commander a tool to 
effectively and efficiently manage his assets. 
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3 . New Insights Gained 

With the concepts presented in this thesis, 
interoperability managers now have a way to better manage 
interoperability requirements. The ideas in this thesis 
provide the basis for the development of a common reference for 
the design of future C2 communications architectures. In 
essence, the MEO concept provides the direction for development 
of interoperability standards. By distinctly characterizing the 
components which define a MEO, interoperability issues on 
several different levels can be addressed. Below are three 
interoperability standards referenced in the ” Marine Corps 
Interoperability Management Plan” [Ref. 13: p. 2-10]: 

(a) Operational Interoperability Standards that specify 
military objectives/operational requirements, tactical 
doctrine/procedures, standard military language, and 
specific information exchange plan. 

(b) Procedural Interoperability Standards that specify 

procedures related to the forms in which information is 
transferred, standards reporting language, and operating 
procedures for data . . . links. 

(c) Technical Interoperability Standards that specify 
functional, electrical, and physical characteristics 
necessary to allow the exchange of information between 
different equipment systems. 

Characterizing interoperability standards is simple in concept, 
but far reaching in terms of future applications. 

4 . Future Directions 



C2 planners can use the tools contained in the MEO 
concept, this thesis, TIC, and MCES to identify the necessary 
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information for an IIDB. In his paper titled, "CUTTING THE 



GORDIAN KNOT OF INTEROPERABILITY: . . Pipho states: 

The Marine Corps is currently in the early stages of 
developing a C2 interoperability database that embodies the 
MEO concept. Figure [4.1] is a diagram of the data model for 
this database as it now stands. The heavy lines indicate 
where the basic components of the MEO are found. Implementa- 
tion of this database is scheduled to occur over the next two 
years. Completion of this project will validate and provide 
the Marine Corps with an effective tool to achieve inter- 
operability among its C2 systems. [Ref. 2] 

Also, needed will be a way to tie measures to the 
IIDB. MCES would be an excellent methodology to apply 
developing these measures and in analyzing interoperability 
requirements . 

C2 planners could ask such questions as: (1) "given 
several implementation of a potential C2 communications 
architecture, which one is significantly better or worse than 
the others?" Or (2) "given a particular collection of resources 
(personnel and equipment), what type of missions can be performed 
and how well can they be executed?" 



B. METHODOLOGICAL ISSUES 
1 . Weaknesses 

As stated previously, the basic idea of the TIC is good. 
But trying to implement the concepts contained in the TIC is 
difficult at best. Some of the OPFAC tasks contained in the 
TIC are ill defined and in many cases it is difficult to asso- 
ciate the "most" appropriate OPFAC task to a given task. There 
were many cases where several OPFAC tasks were required 
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Figure 4.1. Data Model Diagram for the C2 Interoperability Data Base. 










to capture the essence of the task being performed, although 
only portions of each OPFAC task actually related to the given 
task. Figure 4.2 illustrates this point. In this figure one 
can graphically see that, if each of the four OPFAC tasks^ 
narrative descriptions were reduced to the size of the accented 
areas, the OPFAC tasks would be better defined. And as a 
result, C2 planners would not have to wade through unnecessary 
information. Simply eliminating text from an OPFACs narrative 
summary would not necessarily result in a better defined OPFAC 
task. Omitting text would more likely change the connotation 
of the narrative summary, rather than creating a better defined 
OPFAC task. In essence, the functional area category codes which 
are the fourth and fifth digits of an OPFAC tasks number should 
be defined so that they relate to only one task. Then C2 
pla.nners would not have to wade through unnecessary information 
to identify the relationship between tasks and OPFAC tasks, 

2 . Strengths 

The overall concept of this thesis, of distinctly 
characterizing OPFAC tasks, is "usable." Air tasking is 
performed by all services and the author has used an available 
set of tools by combining MCES and the MEO methodology to 
demonstrate this point. By combining these tools the 
author has provided an approach supported by a substantial 
database to address the issue of interoperability management. 
This was not previously possible. 
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OPFAC TASK 60101 



OPFAC TASK 60115 




OPFAC TASK 65015 



Figure 4.2. Mapping OPFAC Tasks to a Given Task • 
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3 . New Insights Gained 

Given that C2Es and message standards are both 
contained in a MEO, and that C2Es can be characterized by the 
organizations that are associated with them, message standards 
should be characterized by the tasks associated with them. 

Along the same reasoning, if C2Es are on different organiza- 
tional levels, they should be classified hierarchically. If 
tasks (functional area categories) are structured hierarchi- 
cally, they create a perfect vehicle to architecturally 
translate a given task into organizational units. But if tasks 
(functional area categories) are not structured hierarchically, 
then it is implied that a given task should be treated the same 
regardless of what level in an organization it pertains to. 
[Ref. 11] 

An additional insight gained from this thesis is 
captured by the illustration in Figure 4.3. Intuitively, the 
author suggests that the six C2 process functions not only have 
a nonsequential execution through feedback loops (as depicted 
in Figure 3.8 and Figure 3.9) but the six C2 functions are not 
mutually exclusive. Essentially all six C2 function are 
involved throughout any C2 process. However, not all C2 
functions may be involved with the same degree of intensity, 
and therefore they may be disregarded. 

4 . Future Directions 

It is clearly evident that there is still much work to 
be done in order to have a useful IIDB. The author recommends 
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the five efforts listed below be undertaken, as soon as 
possible : 

(a) Refine the functional area categories in the TIC, so 
that they more closely relate to the actual tasks per- 
formed for a given mission area* This includes organizing 
and coding the functional area categories on a hierarchical 
structure . 

(b) Identify information requirements for each newly defined 
OPFAC task, based on the information category codes. 

(c) Construct MEOs for all mission areas. 

(d) Once MEOs have been defined, store them, along with their 
components which characterize them, into an IIDB. 

(e) Run queries on the IIDB and use MCES as a tool to analyze 
the MEO concept to improve interoperability management. 

MCES can be expanded to address questions on an architectural 

level, such as: given architecture A and architecture B which 

system can best support a specific combat mission? Once the 

IIDB is operational, it will speed up the analysis of the types 

of problems stated in the previous section (IV. A. 4) titled 

’^OPERATIONAL CONSIDERATIONS, Future Directions.” 

This thesis points out to the C2 community an existing 

approach that the Marine Corps is embarking upon. The C2 

community has not used and does not use this approach, but 

should be aware of it because they can model their own 

service’s unique tools after it. 
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APPENDIX A 



OPERATIONAL FACILITIES (OPFAC) TASKS 
The functional tasks are presented in the following 
paragraphs under the appropriate OPFAC, These OPFAC tasks were 
extracted from the TIC [Ref. 10: pp, D-3 - D-17], The tasks are 

listed in generally the same order as OPFACs are presented in 
the TIC, 

Combat Operations Center - Marine-Air-Ground Task Force Tasks 

. COC MAGTF(M) Task 60000 , Receive initiating 

directive from higher authority; receive planning 
information from all mission planning agencies; develop 
mission plans and operation orders for the conduct of 
operations by subordinate and supporting units of the 
Marine Air/Ground Task Force (MAGTF), Submit plans/ 
orders to supporting agencies for coordination and 
guidance, and to subordinate agencies/units for execution. 

, COC MAGTF(M) Task 60001 , Supervise and coordinate the 
operational planning and tactical execution thereof by 
subordinate and supporting agencies to preserve economy 
and unity of effort, while ensuring the accomplishment of 
objectives of the MAGTF; modify the tasking of supporting 
agencies as required. 

. COC MAGTF(M) 60011 , Ensure, during the planning and 

execution stages, the integration of all air, artillery, 
mortar, and naval gunfire in support of the scheme of 
maneuver of the ground forces. 

, COC MAGTF(M) Task 60012 , Allocate assets to subordinate 
and supporting agencies for the operation when approved 
plans have been promulgated. Request allocation of support 
from higher headquarters when support requirements cannot 
be met from organic assets, 

. COC MAGTF(M) Task 60015 . Maintain the status of the 

capabilities of friendly and enemy forces. Receive opera- 
tional reports and intelligence data from supporting 
agencies; consolidate and forward to cognizant head- 
quarters, keeping them advised of progress toward meeting 
objectives. 
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COC MAGTF(M) Task 60065 . Receive/initiate and disse- 
minate tactical alerts and warnings concerning enemy 
activity and delivery of chemical or nuclear munitions by 
friendly forces, to ensure the safety and tactical 
integrity of force units. 

COC MAGTF(M) Task 60070 . Establish the EMCON/EW policy 
for the MAGTF. 

COC MAGTF(M) Task 60075 . Receive, evaluate, and 
disseminate combat information to support MAGTF 
operations, utilizing reconnaissance and surveillance 
reports, and other reports from units in contact with 
the enemy. 

Combat Operations Center Ground Element Tasks 

COC GE(M) Task 60100 . Receive initiating directive 
from higher authority; receive planning information from 
all mission planning agencies; develop mission plans and 
operation orders for the conduct of operations by sub- 
ordinate and supporting units of the ground element (GE). 
Submit plans/orders to senior headquarters for approval, 
to supporting agencies for coordination and guidance, and 
to subordinate agencies/units for execution. 

COC GE(M) Task 60101 . Supervise and coordinate the 
operational planning and tactical execution thereof by 
subordinate and supporting agencies to preserve economy 
and unity of effort, while ensuring the accomplishment 
of the objectives of the GE; modify the tasking of the 
supporting agencies as required. 

COC GE(M) Task 60111 . Ensure, during the planning 
and execution stages, the integration of all air, 
artillery, mortar, and naval gunfire in support of the 
scheme of maneuver of the ground forces. 

COC GE(M) Task 60112 . Allocate assets to subordinate 
and supporting agencies for the operation when approved 
plans have been promulgated. Request allocation for 
support from higher headquarters when support requirements 
cannot be met from organic assets. 

COC GE(M) Task 60115 . Maintain the status and capa- 
bilities of friendly and enemy forces. Receive opera- 
tional reports and intelligence data from supporting 
agencies; consolidate and forward to cognizant 
headquarters, keeping them advised of progress toward 
meeting objectives. 
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COC GE(M) Task 60165 . Receive/initiate and disseminate 
tactical alerts and warnings of enemy activity, and 
delivery of chemical or nuclear munitions by friendly 
forces, to ensure the safety and tactical integrity of 
force units. 

Tactical Air Command Center Tasks 

TACC(M) Task 65001 . Supervise and coordinate the 
operational planning and tactical execution thereof by 
subordinate and supporting agencies to preserve economy 
and unity of effort, while ensuring the accomplishment 
of the missions of the TACC in support of the MAGTF 
objectives; modify the tasking of supporting agencies as 
required . 

TACC(M) Task 65015 . Maintain complete information on 
the air situation, including that ground combat information 
essential to the air effort. Keep cognizant agencies 
advised . 

TACC(M) Task 65041 . Manage all aircraft in the AOA to 
ensure the most balanced and properly weighted utilization 
of assets for tactical air operations. 

TACC(M) Task 65043 . Develop detailed FRAG orders to 
support the operations of the assault forces. Advise 
supporting arms agencies of the air support schedule in 
order to integrate air support with artillery and naval 
gunfire support. Disseminate the FRAG orders to air units 
and control agencies for execution. 

TACC(M) Task 65052 . Divert aircraft from scheduled 
missions to meet other priority requirements; notify 
affected agencies and brief pilots as required. 

TACC(M) Task 65055 . Establish and promulgate procedures 
for employment of air defense weapons in overlapping sectors 
of responsibility. 

TACC(M) Task 65061 . Coordinate search and rescue 
operations for the MAGTF. 

TACC(M) Task 65065 . Provide appropriate air defense 
alert conditions to all major elements of the MAGTF. 

TACC(M) Task 65068 . Establish alert conditions for 
ground alert aircraft. 
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TACC(M) Task 65070 . Prescribe electronic emission 
control (EMCON) conditions and electronic warfare (EW) 
procedures for MACCS agencies in the objective area. 

TACC(M) Task 65072 . Coordinate the gathering of 
sensor information, including radar contacts and 
electronic emissions, and report the information to 
command elements and air control agencies. 
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APPENDIX B 



FUNCTIONAL AREA CATEGORIES 



The functional area categories listed below are quoted 
directly from the TIC. [Ref. 10; pp. D-4 - D-5] 



PLATJS 


00 


Basic Plans and OPORDs 


04 


Nuclear and Chemical Fire 




01 


Supervise and Coordinate 




Plans 






Planning and Execution 


05 


Fire Support Plan Assistance 






of Plans and Orders 


06 


Artillery Fire Plans 




02 


Su[ifxjrtinq Armi; Plans 


07 


Counter fire I’lans 




01 


Naval Cunt ire Plans 


08 


Air Support Plans 




l(J 


Information Collect if;n 14an.s 






ASSCTS 


11 


Integration of Assets 








12 


Allocation of Assets 






SITUATION 


15 


Friendly and Sneniy Status 


18 


Status Displays/Dissemination 


OK STATUS 


16 


Supporting Arms Situation 


19 


Status of Linainys 




17 


Aircraft Status and 


20 


Unit IiDcation and Status 






Capabilities 


21 


Ftiendly Aircraft Location 


FIRE 


25 


Provide Supporting Arms 


30 


Receive Calls for Fire 


SUPPORT 




Support 


31 


Call for and Adjust Fires 




26 


Monitor Fires/Safety 


32 


Control NGF and Artillery 




27 


Limiting Measures 




Fire 




28 


Coordinate NGF, 


33 


Registration Fires 






Artillery, Mortar Support 


34 


Fire Direction 




29 


Requests for NGF, 


35 


Fire Comma nds/Safety 






Artillery, Mortar Support 


36 


Target Infornation 


AIR 


40 


Command Subordinate 


46 


Provide Air Support 


SUPPORT 




Agencies 


47 


Direct Aar Strikes 




41 


Manage Aircraft 


48 


Control Aircraft 




42 


Coordinate with External 


49 


Assign A/C to Control Agencies 






Agencies 


50 


Requ<;sts for Air Support 




43 


Schedules/FRAG Orders 


51 


Air Support Requirements 




44 


Coordinate Friendly Aircraft 


52 


Adjust/Divert 




45 


Coordinate/ Act for Control 


53 


Coordinate DAlS Execution 






Agencies 


54 


Coordinate FAAD I'eams 




55 


Coordinate Air Defense 


58 


Movement Into and Out of 




56 


Identify and Track Aircraft 




Landing Zone 




57 


Landing Zone Operations 


59 


Provide Aiir Defense 
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APPENDIX B 



FUNCTIONAL AREA CATEGORIES (CONT’D) 



FLIGHT 


60 


Flight Advisories 


63 


GCA/Radar/tiivigation 










Assistance 


ASS IS- 


61 


SAP C^rations 


64 


Air Track Data 


TATCE 


62 


Hadar Handover 






WARNIIX5S 


65 


Receive/Disseminate 


67 


Ordnance Release 


AND 


66 


Nuclear and Chemical 


68 


Strip Alert Data 


ALERTS 




Delivery 






SENSOR 


70 


EMCON/EW Policy 


72 


Coordinate Sensor Data 




71 


Coordinate/Monitor 


73 


Provide Sensor Data 






EMCON/EW 






IiriELL- 


74 


Collect Information 


76 


Reconnaissance and 


GENCE/ 


75 


Process Intelligence Data 
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APPENDIX C 



INFORMATION CATEGORIES 

The information contained in this appendix is quoted from 
the TIC [Ref. 10: pp. 3-5 - 3-7]. 

Information Categories . The JINTACCS program has derived 12 
categories of information from JCS Pub 12 to identify the infor- 
mation exchange requirements among and between various OPFACs. 
When an individual information category is applied to each of 
the 12 operational tasks, the content of the category varies 
according to the task. This application provides for a refine- 
ment of the basic 12 information categories in defining 
information exchange requirements. 

a. Allocation/ Apportionment(AL) . An allocation is 
refinement of the apportionment decision made by the force 
commander. An example is the apportionment decision made by the 
division of the total tactical air capabilities among air strike 
tasks to be performed for a specific period. In consideration 
of the apportionment, the commander prepares the allocation by 
designating specific numbers and types of aircraft sorties for 
use during the specified time period. Necessary allocation 
information is transmitted from the commander(s) to the compo- 
nents included in the apportionment and to the joint task force 
headquarters . 

b. Enemy Capabilities (EC) . This category provides 
intelligence on possible future courses of action by the enemy 
which may affect the accomplishment of the assigned joint task 
force mission. The term "capability” includes not only the 
general courses of action open to the enemy, such as attack, 
defense, or withdrawal, but also all specific courses of action 
possible under each general course of action. Enemy capabili- 
ties are considered in light of all known factors affecting 
military operations, including time, space, weather, terrain, 
and the strength and disposition of enemy forces. It does not 
involve the current situation of the enemy, but deals with 
possible future actions of the enemy. As used in this docu- 
ment, information in this categoryo is generated by an opera- 
tional facility as a result of analyzing and evaluating 
information obtained from its own resources and/or of 
information obtained from other operational facilities, 
including a reassessment of enemy capabilities generated by 
other operational facilities. 

c. Enemy Status (ES) . This category provides information 
and/or finished intelligence on the enemy situation as it cur- 
rently exists. It may include historical intelligence, but it 
excludes possible future actions by the enemy from all sources, 
including order of battle, location and disposition, movement 
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speeds and direction, target and installations, scientific and 
technical, biographic, nuclear, biological, and chemical and 
other information classified as current or combat intelligence 
(e.g., contacts and sightings, electronic warfare, imagery and 
imagery readouts, prisoner-of-war exploitation, and captured 
documents and material) are included in this category, except 
weather (WX) and terrain (TG). 

d . Friendly Capabilities (FC) , This category provides the 
commander’s evaluation of what his unit(s) can or cannot do in 
the future. It does not involve the present situation of friend- 
ly forces, but deals only with possible future actions and 
conditions of these forces. Information in this category includes 
potential courses of action by friendly units which, if adopted, 
will contribute to the accomplishment of the assigned mission. 

It also includes projected status and availability of units, or 
their weapons systems or other material, and estimated future 
strength and location of friendly units. It does not include 
the intention of the commander, but may describe the future 
friendly situation resulting from the pursuit of those 
intentions . 

e . Friendly Status (FS) . This category provides 
information about friendly forces as they currently exist. It 
includes such elements as strength, composition, location and 
dispositon, status and availability of resources, movements and 
activities, movement speeds and direction, logistics, signifi- 
cant strengths and weaknesses, nuclear, biological, and chemical 
weapons, and/or technical characteristics of equipment. It 
describes the friendly situation as it currently exists, not as 
it may exist in the future. 

f. Orders (OR) . This category involves directives to 
take action. It does not include information concerning what 
the commander intends to do in the future, but may tell the 
recipient what the commander requires to be done in the future. 

For weapons systems, it may include instructions such as fire, 
cease fire, track, drop track, vector, attack, etc. It also 
includes such directives as operations orders, warning orders, 
fragmentary orders, etc. 

g . Plans (PL) . This category consists of a method or 
scheme for a future military action. It represents the 
commander’s translation of his decisions and concepts of 
operation into preparing for action in a specific area to meet 
a particular event, and it conveys the commander’s intentions 
for accomplishing this event. A plan will not become an order 
without appropriate implementing instructions. 

h . Priorities (PR) . This category involves the 
commander’s ranking the elements of any situation in the order 
of each element’s importance to the accomplishment of the 
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mission. Priority information may involve establishing the 
precedence of elements relative to time, space, or any number 
of other limiting factors. The ranking indicates relative 
importance; it is not an exclusive and final designation of the 
order of accomplishment. For example, the DASC assigns a 
priority to each request for close air support submitted by 
ground agencies; the TACC assigns priorities for air defense 
protection to specific areas, facilities, units, or activities 
within the area of operations. 

i . Request for Information (RI) . This category tells the 
recipient that information is needed for use in decision making. 
This category does not include requests for support (RS). It is 
not used to obtain information which is otherwise required to be 
transmitted as a result of orders or of execution of plans, but 
is used to obtain information for amplification or clarifica- 
tion, or information that is otherwise excepted from reporting. 
Such requests may be general or specific in nature, and may or 
may not require recurrent responses. It may be used to obtain 
information on enemy or friendly status or capabilities, weather 
or terrain. It may also be used to request further orders from 

a superior, or to interrogate other commanders about their plans 
or priorities. 

j . Request for Support (RS) . This category is part of the 
process of allocating and reallocating combat resources. The 
support requested encompasses any action on the part of an 
agency which aids, protects, complements, or sustains another 
agency when engaged in tactical operations. 

k . Terrain /Geographic/ Oceanographic /Hydrographic 

Information (TG) . This category of information 
pertains to all aspects of the environment, natural or manmade, 
other than weather. It includes the configuration, composition, 
fauna, flora, cultural features, and hy udrological and geophysi- 
cal characteristics of the land and all aspects of the sea. It 
includes navigational information, fallout, effects of chemical 
weapons, induced radiation data, and such mand-made obstacles as 
minefields, barbed wire, concertinas, and underwater barriers. 

l. Weather (WX) . This category of information pertains 
to all past, current, and forecasted meteorological, climatolo- 
gical, and sea conditions. 
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